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Method And Apparatus For Managing network Resources for externally 

Authenticated Users 

FIELD OF INVENTION 

The present invention generally relates to managing resources on a network. The 
5 invention relates more specifically to managing network resources for externally 
authenticated users. 

BACKGROUND OF THE INVENTION 

Network management systems monitor and manage access to internal resources of a 
network. The management systems are commonly used throughout local networks and wide- 

10 area networks such as the Internet. In general, management systems authenticate a user, and 
grant privileges or authorizations for access to the network's resources. Examples of network 
management systems include Resource Management Essentials and CiscoWorks 2000, from 
Cisco Systems, Inc., San Jose, California. 

With some network management systems, users are assigned privileges of a class 

1 5 after they are authenticated. The class identification allows that user to receive privileges for 
accessing that network's resources. The policy that manages the user is tailored for the class. 
For example, users may identify themselves as "administrator." The network may have a 
policy to manage access to specific network resources for the "administrator." 

The user's class status maybe employed throughout that user's administrative 

20 domain, where the user was authenticated. Typically, if such users attempt to carry out an 
operation outside of their currently authenticated administrative domain, the class status is 
not valid anymore. The user may have to be authenticated in a new administrative domain to 
receive a new class status. The effect of this, from the user's perspective, is that the user is 
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repeatedly presented with prompts to enter a username and password as the user moves from 
domain to domain. This interrupts the workflow of the user, and is time-consuming and 
awkward. Therefore, there is a need for a way to authenticate a user once and have the 
authentication remain usable and valid as the user moves among administrative domains. 
5 Many current systems are in place to broaden authentication services for network 

management. One system, Kerberos, developed as part of "Project Athena" at the 
Massachusetts Institute of Technology, provides an encrypted ticket to clients. The clients 
can use the tickets to access network resources. The tickets contain identifications of the 
users. The user's identification is encrypted until the ticket is sent to a service. The service 
1 0 uses an encryption key to identify the user. The ticket also determines information about the 
user's authentication. In this way, the encrypted ticket serves as an authentication for 
attempting to access a supporting service. However, Kerberos is complex to implement and 
requires an extensive supporting infrastructure to work. 

Based on the foregoing, there is a clear need in the field for a way of simplifying 
1 5 identification and authorization processes to allow for easier management of network 
resources to externally authenticated users. 

There is a specific need for a way to identify authenticated users by roles or classes to 
external systems that manage network resources, without using particular identifiers of the 
users. 
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SUMMARY OF THE INVENTION 

An aspect of the invention provides a method of managing network resources for 
externally authenticated users. In one specific aspect, the invention provides a method for 
enabling a user who is authenticated in one administrative domain to be managed as a 
member of a class in another administrative domain. After the user is authenticated in a first 
administrative domain, the user is assigned a role that identifies the user as a member of a 
class. The user can be identified in another administrative domain by the assigned role. The 
assigned role allows the user to access network resources in the other administrative domain 
according a policy identified for that role. 

In other aspects, the invention encompasses a computer apparatus, a computer 
readable medium, and a carrier wave configured to carry out the foregoing. 

Many other aspects and features will become apparent from the following description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example, and not by way of limitation, 
in the figures of the accompanying drawings and in which like reference numerals refer to 
similar elements and in which: 
5 FIG. 1 illustrates a system for managing network resources using a token. 

FIG. 2 is a sequence diagram for a system, such as the system of FIG. 1 . 

FIG. 3 is a flow diagram that illustrates a method for managing network resources for 
externally authenticated users. 

FIG. 4 is a flow diagram that illustrates another method for managing network 
10 resources for externally authenticated users from an administrative domain of a user. 

FIG. 5 is a diagram of an illustrative data structure for a token. 

FIG. 6 is a block diagram that illustrates a computer system upon which an 
embodiment maybe implemented. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A method and system for managing network resources for externally authenticated 
users is described. In the following description, for the purposes of explanation, numerous 
specific details are set forth in order to provide a thorough understanding of the present 
5 invention. It will be apparent, however, to one skilled in the art that the present invention 
may be practiced without these specific details. In other instances, well-known structures 
and devices are shown in block diagram form in order to avoid unnecessarily obscuring the 
present invention. 

A. Overview 

1 0 Certain embodiments provide for managing network resources in multiple 

administrative domains. In an embodiment, a user is authenticated by a component of an 
administrative domain that manages that user. A token is generated for the user after the user 
is authenticated. The token assigns one or more roles to the user. The token is configured to 
identify the user by the assigned role to components of another administrative domain. 

15 As a result, may be provided a single authorization service that is conveniently 

applicable to multiple administrative domains. Different administrative domains may share 
authentication services to conserve resources. Furthermore, users maybe given access to 
different administrative domains while the identities of the users are kept hidden from 
administrative domains that are external to the authenticating administrative domain. 

20 When a user is authenticated, a personal identification of the user is determined. In 

addition, a claimed identity of the user is verified. One conventional manner for 
authenticating users is to require the user to log-in by providing a user name and a password. 

An administrative domain refers to a network domain having a degree of authority to 
manage or control users with internal components of that domain. Different administrative 

25 domains have different degrees of authority to control the same users. Also, different 
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administrative domains may use different components to control users. As an example, a first 
administrative domain may authenticate a user, and a second administrative domain may 
control access to internal resources of that domain through a separate authorization process. 
The second administrative domain may also limit access to the domain by not authenticating 
5 the user, but by treating the user as a class member or unknown. Each administrative domain 
includes one or more network devices, such as switches, routers, gateways, etc., and/or one 
or more network end stations, such as workstations, printers, storage devices, etc. 

In one embodiment, one administrative domain is used to keep an account for a set of 
users. An account can store log-in information, such as user names and passwords, to 

1 0 authenticate its users. An account may also store other information, such as a log that records 
access to the administrative domain by each user. Account information may be maintained in 
an access, authentication and accounting (AAA) server, such as a RADIUS server, in a 
Kerberos authentication server, or any other suitable system. 

As used herein, if an authentication process for authenticating particular users is 

1 5 under the control of one administrative domain, that authentication process is not under the 
control of another administrative domain. Furthermore, a first domain may use the final 
result of an authentication process in a second domain, but the first domain cannot control the 
authentication component that is accessed by the user. As will be described, embodiments 
allow for users to be authenticated in their own administrative domain, and to use that 

20 authentication to access resources in another administrative domain that does not directly 
manage the user. 

A token is a data element that is signaled from a terminal as part of a network 
communication. The token may include multiple types of information. For example, a token 
may include an identity of the user, a class assigned to the user, information about the quality 
25 of the authentication, and/or a time stamp. The token may reside on a terminal of the user, 
where it is automatically signaled with network communications from that terminal to 
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targeted domains. Alternatively, the token may reside on an external computer, and may be 
accessed by components that use it for purpose of network management. 

A role is an identification to associate a user as a member of a class. The role 
provides a criteria or selection parameter that can be used to identify a policy for managing 
5 access to network resources. The selection parameter identified by the role is different than a 
user's personal identification. A class can have one or more users as members. In addition, a 
class can be identified without requiring any of the members to be identified. 

In an embodiment, the token is configured to be accepted by a policy server. The 
policy server identifies the user as a member of a class identified by the token. Privileges 

10 may be extended to the user by a policy of the policy server. The privileges may be 
uniformly extended to all members of the class that use the same policy server. 

Resources that can be managed on an administrative domain include, for example, 
files, network pages, executable programs, storage space, and communication channels. 
Resources may be Web-based, such as, for example Web pages, other HTML documents, or 

1 5 Web-based applications. 

In another embodiment, a system for managing network resources may be 
implemented on a computer system comprising processing resources and a storage medium. 
Processing resources are one or more processors, operating in cooperation. A storage 
medium is one or more memory components operating in cooperation. 

20 A domain, administrative domain, component of a domain, policy, server, policy 

server, and other elements described herein may be represented in the form of one or more 
data representations, abstract data structures, or other information that is created and stored in 
a computer-readable medium, and managed by one or more software elements. Such data 
representations may be processed by a network management station, policy manager, or other 

25 processor to accomplish the methods described herein. 
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B. System Description 

FIG. 1 illustrates a system for managing network resources using a token. 

A user 101 is associated with a client 105 that is communicatively coupled to a 
network. Client 105 is a workstation, personal computer, or other network end station device; 
5 alternatively, client 105 is a network infrastructure device such as a router, switch, gateway, 
etc. 

The network includes a first administrative domain 110 and a second administrative 
domain 120. First administrative domain 1 10 includes an authorization ("AUTH") 
component 115. Second administrative domain 120 includes an application 125 having one 

10 or more network resources 128. The application 125 interacts with a policy server 135, which 
has access to a policy database 138. Each of the foregoing elements is communicatively 
coupled directly or indirectly through one or more networks or internetworks. In one 
embodiment, first administrative domain 110 and second administrative domain 120 are 
logical domains of a campus network; in other embodiments, the domains are widely 

15 geographically distributed. 

For purposes of illustrating a simple example, FIG. 1 shows one user and client, two 
administrative domains, and one authentication component. However, in an implementation, 
there may be any number of such elements. 

The user 101 operates client 105 to access the first administrative domain 1 10. The 

20 first administrative domain 1 10 is where management and administration components reside 
for user 101 . The user 101 may signal an authentication request 1 12 to first administrative 
domain 1 10 to receive an authorization. An authentication component 115 may be located in 
first administrative domain 1 10 to authenticate or verify the identity of user 101 from 
authentication request 112. The authentication component 115 manages an account for user 

25 101. In one implementation, user 101 signals login information, such as a user name and 
password, to the authentication component 1 15. An authentication process conducted by 
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authentication component 1 1 5 verifies the submitted login information with stored login 
information in the user's account. 

Once authenticated, user 101 maybe provided privileges and constraints for 
accessing network resources from other components of first administrative domain 110. Such 
5 privileges and constraints define how the user is authorized to access such network resources. 
The user may, for example, access a management component on first administrative domain 
1 10 that manages access to certain resources, such as files, information, or executable 
programs. These other components may receive communications from a policy server (not 
shown) or other component of the first administrative domain to identify a policy governing 

1 0 the privileges and constraints of the user 1 0 L 

In other systems, the user's authentication was valid only for first administrative 
domain 110, because the user's account was maintained in that domain. In contrast to the 
other systems, embodiments of the invention provide for the authentication received in first 
administrative domain 1 10 to be transferable to other administrative domains. 

15 In an embodiment, the authentication in first administrative domain 1 1 0 is 

transferable to second administrative domain 120 by way of a token 118. The token 1 1 8 may 
be generated on authentication component 1 15, or another component of first administrative 
domain 1 10. In an example provided, the token 1 18 is signaled to second administrative 
domain 120 with a request 122 to access network resources in that domain. As will be further 

20 described, an embodiment provides that token 1 1 8 identifies user 101 as a role to a 
component of second administrative domain 120. 

The second administrative domain 120 includes an application 125 that manages 
network resources 128. The application 125 securely manages the resources 128 to prevent 
unauthorized access. The application 125 communicates with a policy server 135 to access a 

25 policy from a policy repository 138. The application 125 uses the policy to grant the user 101 
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access to resources 128. Different policies may be used to manage users that request access 
to resources 128. 

In an embodiment, token 1 18 is provided from client terminal 105 to application 125. 
The token 1 1 8 is provided while a network session initiated when user 101 was authenticated 

5 on first administrative domain 1 10 is still ongoing. The application 125 signals token 1 1 8 to 
policy server 135. The policy server 135 uses token 1 18 to identify the role assigned to the 
user by authentication component 1 15 of first administrative domain 110. The policy server 
135 selects a policy from policy repository 138 using the role identified from the token. The 
application 125 manages access to resources 128 using the policy selected from policy server 

10 135. 

In one implementation, the token may be used in both of the first and second 
administrative domains 1 10, 120. As such, policy servers in either domain can identify a 
policy for the user. The policies may be different for different domains. 

Another feature provided under an embodiment is that authentication of the user takes 
15 place in first administrative domain 1 10, but the policy that dictates the user's access to 

resources on second administrative domain 120 can be generated from the policy server 135 
of the second administrative domain 120. 

In this way, the second administrative domain 120 does not have to relinquish control 
of its policies to the first administrative domain 1 10 to enable users of the first administrative 
20 domain to access its resources. The first administrative domain 110 also does not have to 

divulge the identification of one of its users. Furthermore, second administrative domain 120 
may provide resources to a user that is not being managed in that domain, but rather in first 
administrative domain 110. 

In one implementation, first administrative domain 110 and second administrative 
25 domain 120 each correspond to an Internet Service Provider (ISP). The user 101 may be a 
member of the ISP corresponding to first administrative domain 1 10. The authentication 
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component 115 may, for example, be conducted during a dial-up process to couple client 
terminal 105 with the ISP. 

During the authentication process, user 101 may be provided with token 1 1 8 for use 
with the second ISP, corresponding to second administrative domain 120. It is also possible 
5 for the token to be configured for use with the first ISP, corresponding to first administrative 
domain 1 1 0. The client terminal 105 may access the second ISP using a connection 
established with the first ISP. The token 1 18 may be submitted by the user automatically with 
a request to application 125 to access a Web-based resource. For example, application 125 
may manage access to resources 128 that include a game, message center with chatting, 
10 streaming audio, etc., and/or a members-only search engine and database. The user 101 may 
request access to one of the games or the message center. 

The token 118 identifies user 101 by a role. For example, the token may identify user 
101 as a subscriber to the first ISP. The application 125 signals token 1 18 to policy server 
135 for the second ISP. The policy server 135 uses the role to identify a policy for user 101 . 
15 In one implementation, the role provided to the user in the first domain 1 1 0 may be 

mapped by the policy server 135 (or another component of the second domain) to another 
role for the second domain 120. Thus, the user may have one role in the first ISP, and that 
role is mapped by the second ISP to give that user another role in the second ISP. The 
mapped role provided to the user in the second ISP is used for determining the policy of that 
20 user in the second ISP. Likewise, the role provided to the user in the first ISP is used to 
determine the policy for the user in the first ISP. 

In the example, the policy selected may correspond to a policy for all members of the 
first ISP. To further the example, the policy retrieved by policy server 135 may dictate that, 
as a subscriber of the first ISP, user 101 is to be provided access to resources that coincide 
25 with games, the message center, a depository of messages, but not the members-only search 
engine and database. The application 125 serves requests from user 101 and provides the 
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resources 128 as dictated by the policy. If the user 101 requests access to the members only 
search engine, the request is denied. 

Using a system such as described with respect to FIG. 1 , token 1 1 8 can be configured 
to hide the identity of user 101. Therefore, the first ISP and second ISP may agree to share 
5 resources for users, but neither ISP has to reveal the identity of their subscribers. Thus, the 
ISPs may protect their customer bases, while sharing their resources with their mutual 
customers. 

In one implementation, business logic may exist between the first administrative 
domain 110 and second administrative domain 120 to allow the administrative domains to 
10 share resources with users. For example, the first ISP and second ISP may share a billing 
policy. The second ISP may charge the first ISP for users of the first ISP that access 
resources on the second ISP. The first ISP may then bill its users for accessing the second 
ISP. This avoids the second ISP from having to bill the user of the first ISP directly. 

FIG. 2 is a sequence diagram for a system, such as described herein with FIG. 1 . 
15 According to an embodiment, client 105 signals a request 201 to be authenticated by 

authentication component 1 15 in first administrative domain 1 10. The authentication 
component 1 1 5 returns a signal 203 confirming or denying the authentication request. The 
signal 203 may carry token 1 1 8 as shown in FIG. 1 . 

If the signal 203 confirms the authentication request, client 105 is free to access 
20 application 125. 

The client 105 then may signal a request 205 for resources from application 125, 
which manages resources 128 in second administrative domain 120. The request 205 may 
carry token 118. The application 125 submits the token 1 18 to policy server 135 in a policy 
request 207. The policy server 135 uses the role identified in token 1 1 8 to select a policy for 
25 the user. The policy server 135 returns the selected policy 209 to application 125. The 

application 125 uses the policy 209 to signal a request 211 for resources 128. The resources 
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are returned to client 105 in a response 213. Alternatively, the resources may be made 
available to a user of client 105 on another computer. 

As a result, the client can access resources in multiple administrative domains after 
undergoing only one authentication process. 
5 C. Method Descriptions 

FIG. 3 is a flow diagram that illustrates a method for managing network resources for 
externally authenticated users. 

FIG. 4 is a flow diagram that illustrates another method for managing network 
resources for externally authenticated users from an administrative domain of a user. 
10 For purpose of illustrating a simple example, the methods of FIG. 3 and FIG. 4 are 

described herein in the context of FIG. 1 and elements of FIG. L However, the methods of 
FIG. 3 and FIG. 4 are not limited to that specific context, but are broadly applicable for 
purposes identified in this disclosure. 

The method of FIG. 3 may assign users to roles that are subsequently used to identify 
15 policies for accessing resources on different administrative domains. 

In step 310, a user is authenticated in first administrative domain 1 10. As described, 
the authentication process may require the user to submit login information such as a user 
name and/or password. Alternatively, the authentication may be made through other 
mechanisms, such as a secure cookie. 
20 In step 320, a token is generated that assigns a role to the user. For example, the user 

may be assigned a "general" role to enable access only to public resources on different 
administrative domains. Alternatively, the user may be assigned an "administrator" role to 
enable the user to access highly secure resources in different administrative domains. 

In step 330, the token is provided to an application in second administrative domain 
25 120. The application may manage resources in the second administrative domain 120. 
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In step 340, a policy is determined for the role identified for the user by the token. For 
example, if the identified role is "administrator", then the policy may allow the user to access 
secure resources on second administrative domain 120, even though the user was 
authenticated on first administrative domain 1 10. In an embodiment, a role is provided to the 
5 user in first administrative domain 1 10. The second administrative domain 120 identifies a 
policy for that role by first mapping the role of the first administrative domain to a role used 
by the second administrative domain. 

In step 350, the user is allowed to access the resources on second administrative 
domain 120 according to the policy determined in step 340. Thus, the request for secure 
10 resources may be allowed if the policy in step 340 is that of" administrator". 

Referring now to FIG. 4, in another example, multiple users are assigned the same 
role in one administrative domain, and that role is used to select a policy to access network 
resources in another administrative domain. 

In step 410, an authentication request is received from multiple users of a first 
15 administrative domain 1 10. In step 420, the users are individually authenticated. The 
authentication process is performed by an administrative component of the first 
administrative domain 110. 

In step 430, the authenticated users are assigned a role. The role is an identifier for 
policy servers on different administrative domains. Other features of the token may also be 
20 used to identify the policy for that user. As such, the users are identified by the role to the 
other policy servers. A user's individual identification may become irrelevant to external 
administrative domains after that user is authenticated in the user's administrative domain. In 
one embodiment, the identity of the users may be hidden or encrypted from other policy 
servers, so that each user is identifiable only by assigned role. 
25 In step 440, authenticated users are enabled so as to be identifiable on other 

administrative domains by the assigned roles. In an embodiment such as described with FIG. 
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1 , step 440 may involve generating information, which may be packaged in data structures 
such as tokens, and which can then be signaled to components of the other administrative 
domains. The client 105 of FIG. 1, for example, maybe configured to signal the token with 
all communications to other administrative domains. 
5 The first and second administrative domains 110, 120 may include logic to enable 

resources and policies to be shared between the administrative domains. For example, 
business logic between the two administrative domains may enable the second administrative 
domain 120 to bill a proprietor of first administrative domain 1 10 for services provided to 
users of first administrative domain. The bills are for users who were identified as being from 
10 the first administrative domain 110, rather than for users that were identified on an individual 
basis. 

In other embodiments, the assigned role may be associated with the user on another 
computer. Communications by the user to other administrative domains includes informing 
the components of the other administrative domains of the existence and location of the role 
1 5 associated with a particular user. The components of the other administrative domain may 
then access the computer where that role is stored. 

D. Token Description 

FIG. 5 is a diagram of an illustrative data structure for a token. The example data 
structure of FIG. 5 is intended to illustrate one possible structure for the contents and/or 
20 functions of a token 500. 

Some elements of token 500 include: (i) an element 510 to indicate one or more roles 
510 that the corresponding user may occupy, (ii) an element 520 to indicate a version of the 
application used to create token 500, (iii) an element 530 to indicate the authentication 
quality in which the token 500 was created, (iv) a creation time stamp 540 to indicate when 
25 token 500 was created, (v) an expiration time stamp 550 to indicate when token 500 is to be 
expired, and (vi) a handle 560 to provide information about the token at a user-level and/or at 



50325-0548 (Seq. No. 4030) 



-15- 



a programmer's level. The information that can be provided by handle 560 includes a user's 
identification, at least one of the roles assigned to the user, and a network address of the user. 
The handle 560 may also provide, for example, an address of the authentication component 
that authenticated the user. 
5 In an embodiment, some or all of the information provided in token 500 may be 

hidden from components of external administrative domains. In one implementation, the 
identification of the user is encrypted. The address of the user may also be encrypted. This 
may require encrypting all or portions of handle 560. 

Several variations are possible. For example, token 500 may be configured to enable 

10 the user to occupy any one of the roles Rl, R2 and Rn in element 510 on an external 

administrative domain. The expiration time of element 550 maybe associated with specific 
roles Rl, R2 of element 510, while other roles in element 510 are not assigned an expiration 
time. Thus, if Rl coincides with an "administrator" role, the token 500 may provide that this 
role expires after a set time limit. The same user, however, maybe given concurrently a 

15 "general" role that is indefinite for the duration of the network session. 

Other information that may be included with token 500 may indicate a source where 
the token was created. For example, an Internet Protocol address may be provided for an 
authentication component (or other component) that created token 500. 

There are numerous ways in signaling token 500 to applications for requests to 

20 resources. In Web-based applications, for example, a communication header to an application 
of an external administrative domain may include the token 500. Alternatively, the 
communication header may include an indication that token 500 exists, along with an address 
and a pointer to where the token 500 resides while its user is engaged in an ongoing network 
session. In either case, applications in other administrative domains need to be configured to 

25 receive the token 500 and to identify its information. 
E. Hardware Overview 
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FIG. 6 is a block diagram that illustrates a computer system upon which an 
embodiment may be implemented. 

FIG. 6 is a block diagram that illustrates a computer system 600 upon which an 
embodiment of the invention may be implemented. Computer system 600 includes a bus 602 
5 or other communication mechanism for communicating information, and a processor 604 
coupled with bus 602 for processing information. Computer system 600 also includes a main 
memory 606, such as a random access memory ("RAM") or other dynamic storage device, 
coupled to bus 602 for storing information and instructions to be executed by processor 604. 
Main memory 606 also may be used for storing temporary variables or other intermediate 

10 information during execution of instructions to be executed by processor 604. Computer 
system 600 further includes a read only memory ("ROM") 608 or other static storage device 
coupled to bus 602 for storing static information and instructions for processor 604. A 
storage device 610, such as a magnetic disk or optical disk, is provided and coupled to bus 
602 for storing information and instructions. 

1 5 Computer system 600 may be coupled via bus 602 to a display 612, such as a cathode 

ray tube ("CRT"), for displaying information to a computer user. An input device 614, 
including alphanumeric and other keys, is coupled to bus 602 for communicating information 
and command selections to processor 604. Another type of user input device is cursor 
control 616, such as a mouse, a trackball, or cursor direction keys for communicating 

20 direction information and command selections to processor 604 and for controlling cursor 
movement on display 612. This input device typically has two degrees of freedom in two 
axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify 
positions in a plane. 

The invention is related to the use of computer system 600 for managing network 
25 resources for externally authenticated users. According to one embodiment of the invention, 
a policy determinitive identification such as a token is provided by computer system 600 in 
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response to processor 604 executing one or more sequences of one or more instructions 
contained in main memory 606. Such instructions may be read into main memory 606 from 
another computer-readable medium, such as storage device 610. Execution of the sequences 
of instructions contained in main memory 606 causes processor 604 to perform the process 
5 steps described herein. In alternative embodiments, hard- wired circuitry may be used in 
place of or in combination with software instructions to implement the invention. Thus, 
embodiments of the invention are not limited to any specific combination of hardware 
circuitry and software. 

The term "computer-readable medium" as used herein refers to any medium that 

1 0 participates in providing instructions to processor 604 for execution. Such a medium may 
take many forms, including but not limited to, non- volatile media, volatile media, and 
transmission media. Non- volatile media includes, for example, optical or magnetic disks, 
such as storage device 610. Volatile media includes dynamic memory, such as main memory 
606. Transmission media includes coaxial cables, copper wire and fiber optics, including the 

15 wires that comprise bus 602. Transmission media can also take the form of acoustic or light 
waves, such as those generated during radio-wave and infra-red data communications. 

Common forms of computer-readable media include, for example, a floppy disk, a 
flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other 
optical medium, punchcards, papertape, any other physical medium with patterns of holes, a 

20 RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a 
carrier wave as described hereinafter, or any other medium from which a computer can read. 

Various forms of computer readable media may be involved in carrying one or more 
sequences of one or more instructions to processor 604 for execution. For example, the 
instructions may initially be carried on a magnetic disk of a remote computer. The remote 

25 computer can load the instructions into its dynamic memory and send the instructions over a 
telephone line using a modem. A modem local to computer system 600 can receive the data 
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on the telephone line and use an infra-red transmitter to convert the data to an infra-red 
signal. An infra-red detector can receive the data carried in the infra-red signal and 
appropriate circuitry can place the data on bus 602. Bus 602 carries the data to main memory 
606, from which processor 604 retrieves and executes the instructions. The instructions 
5 received by main memory 606 may optionally be stored on storage device 610 either before 
or after execution by processor 604. 

Computer system 600 also includes a communication interface 618 coupled to bus 
602. Communication interface 618 provides a two-way data communication coupling to a 
network link 620 that is connected to a local network 622. For example, communication 
10 interface 61 8 may be an integrated services digital network ("ISDN") card or a modem to 
provide a data communication connection to a corresponding type of telephone line. As 
another example, communication interface 618 may be a local area network ("LAN") card to 
provide a data communication connection to a compatible LAN. Wireless links may also be 
implemented. In any such implementation, communication interface 618 sends and receives 
1 5 electrical, electromagnetic or optical signals that carry digital data streams representing 
various types of information. 

Network link 620 typically provides data communication through one or more 
networks to other data devices. For example, network link 620 may provide a connection 
through local network 622 to a host computer 624 or to data equipment operated by an 
20 Internet Service Provider ("ISP") 626. ISP 626 in turn provides data communication services 
through the world wide packet data communication network now commonly referred to as 
the "Internet" 628. Local network 622 and Internet 628 both use electrical, electromagnetic 
or optical signals that carry digital data streams. The signals through the various networks 
and the signals on network link 620 and through communication interface 618, which carry 
25 the digital data to and from computer system 600, are exemplary forms of carrier waves 
transporting the information. 
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Computer system 600 can send messages and receive data, including program code, 
through the network(s), network link 620 and communication interface 618. In the Internet 
example, a server 630 might transmit a requested code for an application program through 
Internet 628, ISP 626, local network 622 and communication interface 61 8. In accordance 
5 with the invention, one such downloaded application provides for enabling administrative 
components to configure client communications so as to signal to another administrative 
domain a policy determinitive identification, as described herein. 

The received code may be executed by processor 604 as it is received, and/or stored 
in storage device 610, or other non-volatile storage for later execution. In this manner, 
1 0 computer system 600 may obtain application code in the form of a carrier wave. 
F. Conclusion 

In the foregoing specification, the invention has been described with reference to 
specific embodiments thereof. It will, however, be evident that various modifications and 
changes may be made thereto without departing from the broader spirit and scope of the 
1 5 invention. The specification and drawings are, accordingly, to be regarded in an illustrative 
rather than a restrictive sense. 
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